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Abstract 

This paper introduces Dexpler, a software package which 
converts Dalvik bytecode to Jimple. Dexpler is built on top 
of Dedexer and Soot. As Jimple is Soot's main internal rep- 
resentation of code, the Dalvik bytecode can be manipu- 
lated with any Jimple based tool, for instance for performing 
point-to or flow analysis. 

Categories and Subject Descriptors D.3.4 [Software]: 
Programming Languages — Code generation 

General Terms Code Generation 

Keywords Dalvik Bytecode, Android, Soot, Jimple, Static 
Analysis 

1. Introduction 

Android applications are mainly written in Java. However, 
they are not distributed as Java bytecode but rather as Dalvik 
bytecode. Indeed, the original Java code is first compiled into 
Java bytecode which is then transformed into Dalvik byte- 
code by the dx tool 1 . Dalvik bytecode is register based and 
optimized to run on devices where memory and processing 
power are scarce. 

Analyzing Android applications with Java static analysis 
tools means either that the Java source code or the Java byte- 
code of the Android application must be available. Most of 
the time, Android applications developers do not distribute 
the source code of their applications. One must then analyze 
the bytecode, for instance for malware detection. 



1 dx is part of the Android SDK available at http: //developer . 
android . com/ sdk/index . html 
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Thus, to analyse Android applications, one is forced to 
use a Dalvik disassembler such as Smali [2] or Androguard 
[5]. The problem with disassemblers is that they generaly 
use their own representation of the bytecode which prevents 
them to use existing tools. 

Another possibility is to first convert Dalvik bytecode to 
Java bytecode using Ded [7], Dex2jar [16] or undx [17] and 
then use Java tailored static analysis tools such as Soot [20], 
BCEL [4] or WALA [9]. Tools which generate Java bytecode 
can leverage existing Java bytecode analyzers. However, the 
conversion from Dalvik to Java bytecode could be avoided 
by directly converting Dalvik bytecode to the internal repre- 
sentation of a tool. 

We introduce Dexpler 2 , a Soot modification which allows 
Soot to directly read Dalvik bytecode and perform analysis 
and/or transformation on it's internal Jimple representation. 
Using this method eliminates the intermediate Dalvik to Java 
bytecode conversion step and enables to use a faster and 
simpler tool chain for static analysis. Dexpler only uses a 
disassembler and then does the rest of the work itself or by 
using Soot. 

The contributions of this paper are the following: 

• we describe a Dalvik to Jimple converter tool 

• we provide a comprehensive table which maps Dalvik 
bytecode instructions to Jimple statements 

The reminder of this paper is organized as follows. In 
Section 2 we explain what Soot is, and how it has been mod- 
ified to handle Dalvik bytecode. Section 3 is an overview of 
the Dalvik bytecode. In Section 4 we propose a Soot mod- 
ification called Dexpler which enables Soot to read Dalvik 
bytecode. In Section 5 we evaluate Dexpler on test cases 
and on one Android application, present and discuss the re- 
sults. Section 6 explains the current limitation of our tool. 
We present the related work in Section 7. Finally we con- 
clude the paper and discuss open research challenges in Sec- 
tion 8. 



2 Dexpler webpage: http : / /www . abartel . net/dexpler/ 



2. Soot 

In this Section we give a brief overview of Soot and then 
describe how we incorporate Dexpler in Soot. 

2.1 Soot Overview 

Soot [11, 20] was created as a Java compiler testbed at 
McGill University. It has evolved to become a Java static 
analysis and transformation tool. 

Soot can be used as a code analyzer to, among others, 
check that certain properties hold [22] or guarantee correct- 
ness of programs [8]. 

Multiple tools based on Soot have been developed to 
perform transformations such as translation of Java to C 
[21], instrumentation of Java programs [23], obfuscator for 
Java [18], software watermarking [3], ... 3 . 

Soot accepts Java source code, Java bytecode and Jim- 
pie source code as input files. Whatever the input format, 
it is converted into Soot's internal representation: Jimple. 
Java sIMPLE, is a stack-less, three address representation 
which features only 15 instructions. Any method code can 
be viewed as a graph of Jimple statements associated with a 
list of Jimple local variables. 

2.2 From Java Bytecode to Jimple 

We now describe how Soot handles Java bytecode classes. 
In a typical case, Soot is launched by specifying the tar- 
get directory as a parameter. This directory contains the 
code of the program to analyze, called Application Code 
(only Java bytecode in this example). First, the mainO 
method of the Main class is executed and calls Scene . load 
NecessaryClasses () . This method loads basic Java classes 
and then loads specific Application classes by calling 
loadClassO. Then, SootResolver .resolveClassO 
is called. The resolver calls SourceLocator . getClass 
Source () to fetch a reference to a ClassSource, an in- 
terface between the file containing the Java bytecode and 
Soot. In our case the class source is a Cof f iClassSource 
because it is the coffi module which handles the conversion 
from Java bytecode to Jimple. When the resolver has a refer- 
ence to a class source, it calls resolve () on it. This meth- 
ods in turn calls soot . cof fi .Util . resolveFromClass 
File () which creates a SootClass from the corresponding 
Java bytecode class. All source fields of Soot class' methods 
are set to refer to a Cof f iMethodSource object. This object 
is used later to get the Jimple representation of the method. 

For instance, if during an analysis with Soot the anal- 
ysis code calls SootMethod.getActiveBodyO and the 
Jimple code of the method was not already generated, 
getActiveBody () will call Cof f icMethodSource . get 
BodyO to compute Jimple code from the Java bytecode. 
The Jimple code representation of the method can then be 
analyzed and/or transformed. 
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Figure 1. Dalvik Dex and Java Class 



2.3 Soot and Dalvik 

Soot is missing a Dalvik to Jimple transformation module. 
We implemented such a module called Dexpler and incorpo- 
rated it to Soot using the same structure as Soot's Java byte- 
code parser module, coffi by adding the DalvikClassSource 
and DalvikMethodSource classes. 

3. Dalvik Bytecode 

We present in this Section the structure of a . dex file con- 
taining Dalvik classes and Dalvik bytecode. 

3.1 Overall Structure 

A single Dalvik executable is produced from N Java byte- 
code classes through the dx compiler. The resulting Dalvik 
bytecode is stored in a . dex file as represented in Figure lb. 

As represented in Figure la, there is only a single place 
where literal constant values are stored (constant pool) per 
Java class. It is heterogeneous since different kind of Objects 
are mixed together (ex: Class, MethodRef, Integer, String, 
...). A .dex file contains four homogeneous constants pools: 
for Strings, Class, Fields and Methods. It is shared by all 
the classes. A . dex file contains multiple Class Definitions 
each containing one or more Method definition each of those 
being linked to Dalvik bytecode instructions present in the 
Data section. 

3.2 Dalvik Instruction 



3 see https : //svn. sable .mcgill . ca/wiki/index . cgi/SootUsers 
for a comprehensive list 



The Dalvik virtual machine is register based. This means 
most instructions must specify the registers which they ma- 



int i = 0; 00: const/4 vO, #int 

Object o = null; 01: const/4 vl , #int 

(Java) (Dalvik) 



Figure 2. Dalvik Representation of null and zero 



nipulate. Registers could be specified on 4, 8 or 16 bits de- 
pending on the instruction. 

There are 237 opcodes present in the Dalvik opcode con- 
stant list 4 . However, 12 odex (optimized dex) instructions 
can not be found in Android applications Dalvik bytecode 
as they are unsafe instructions generated within the Android 
system to optimize Dalvik bytecode. Moreover, 8 instruc- 
tions were never found in application code [15]. According 
to those numbers, only 217 instructions can be found in An- 
droid PacKages (.apk) in practice. 

The set of instructions can be divided between instruc- 
tions which provide the type of the registers they manipulate 
(ex: sub-long vl, v2, v3) and those which do not (ex: 
const vO , OxBEEF). Moreover, there is no distinction be- 
tween NULL and which are both represented as (see Fig- 
ure 2). As we will see in Section 4, the lack of type and the 
NULL representation become problematic when translating 
the Dalvik bytecode to Jimple. 

4. Dexpler 

This section describes Dexpler, the Dalvik to Jimple con- 
verter tool. It leverages the dedexer [14] Dalvik bytecode 
disassembler and the Soot fast typing Jimple component im- 
plementing a type inferrence algorithm [1] for local vari- 
ables. We first give a brief overview on dedexer and on how 
Dexpler is working in Sections 4.1 and 4.2, respectively. 
Then, we detail issues we have to deal with. 

4.1 Dedexer 

Our tool leverages dedexer a Dalvik bytecode parser and 
disassembler which generates Jasmin [10, 12] like text files 
containing Dalvik instructions instead of Java instructions. 
We generate Jimple classes, methods and statements from 
the informations provided by dedexer'^ dex file parser. 

4.2 Overview 

Dalvik bytecode instructions are first mapped to Jimple 
statements and registers mapped to Jimple local variables. 
The type of local variables is set to UnknownType. Then, 
Soot's Jimple component, fast typing, is applied to infer the 
type of the local variables. The third and last step consists 
in applying Soot's Jimple pack jop, which features com- 
ponents such as nop eleminitor, to optimize the generated 
Jimple code. 



dalvik/bytecode/Opcodes.java 



4.3 Instruction Mapping 

Each Dalvik instruction is mapped to a corresponding (or 
a group of) Jimple statements. A comprehensive mapping 
is represented in Table 1 in Appendix A. Unused opcodes 
are marked as '-' and odex opcodes as 'odex\ There are 
five main groups of instructions: move instructions (0x01 to 
OxlC), branch instructions (0x27 to 0x3D), getter and set- 
ter instructions (0x44 to 0x6D), method invoke instructions 
(0x6E to 0x78) logic and arithmetic instructions (0x7B to 
0xE2). 

4.4 Type Inference 

The type for local variables is inferred using the fast typing 
Soot component. However, the inference algorithm some- 
time generates an exception and stop because some Dalvik 
instructions (such as the constant initialization instructions 
0x12 to 0x19) do not provide enough information and thus 
confuse the inference engine. 

The lack of type is present in the following instructions: 

• null initialization instructions (zero or null?) 

• initialization instructions (32 bits: integer or float?, 64 
bits: long or double?) 

Null Initialization Figure 4 illustrates the problem with a 
bytecode snippet generated from the Java code of Figure 3. 
Register vO is initialized with at 01. At this point we do 
not know if vO is an integer, a float or a reference to an 
object. At 02 we still do not have the answer. We have to 
wait until instruction at 04 to known that the type of vO is 
Coordinate. At this point, the Jimple instruction generated 
for 01 has to be updated to use NullConstant instead of the 
default IntConstant (0) . If this is not handled correctly, 
the fast typing component generates an exception and stops. 

Numeric Constant Initialization Similarly, float constants 
initialization cannot be distinguished from int constants ini- 
tialization and double constants initialization from long con- 
stants initialization. Thus, we go through the graph of Jim- 
ple statements to find how constants are used and correct 
the initializations Jimple statements when needed. For in- 
stance, if a float/int constant (initialized by default to int 
in the Jimple statement) is later used in a float addition, 
the constant initialization changes from IntConstant (c) 
to FloatConstant (Float . intBitsToFloat (c) ) . 

We implemented the algorithm described by Enck et al. 
[6]. It is based on algorithms which extract typing informa- 
tion for a variable by looking at how it is used in opera- 
tions whithin which the type of the operands is knows (ex: 
the variable is used as a parameter of a method invocation) 
[13, 19]. For each ambiguous register declaration, the algo- 
rithm performs a depth first search in the control flow graph 
of Jimple statements to find out how the declared local vari- 
able dv (registers are mapped to Jimple local variables) is 
used. The type of dv is exposed with the following state- 



Coordinate newCoord = null; 
while (newCoord !=null) { 
newCoord = new Coordinated , 1) ; 

} 

if (newCoord == null) { 
[...] 

} 



Figure 3. Illustration of the null init problem. 

00: const/4 vl, #int 1 

01: const/4 vO, #int 

02: if-eqz vO, 000a 

04: new-instance vO, LCoordinate; 

06: invoke {vO, vl , vl}, LCoordinate ;. <init> : (II) V 

09: goto 0002 

0a: if-nez vO, 0013 

[...] 

13: ... 



Figure 4. Resulting Dalvik Bytecode from Figure 3 

ments: comparison with a known type, instructions operat- 
ing only on specific types (ex: neg-float), non-void return 
instructions and method invocation. The search in a branch 
of the graph is terminated if either the local variable is reas- 
signed (new declaration) or if there is no more statement that 
follow the current one (eg: the current statement is a return 
or throw statement). When the type information is found it 
is forward propagated to all subsequent ambiguous uses be- 
tween the target ambiguous declaration of dv and any new 
declaration of dv. 

4.5 Handling Branches 

Dalvik instructions are mapped to Jimple statements. When 
parsing Dalvik bytecode, we keep a mapping between byte- 
code instructions addresses and Jimple statements. Thus, 
when a Dalvik branch instruction is parsed, a Jimple jump 
instruction is generated and its target is retrieved by fetching 
the Jimple statement mapped to the Dalvik branch instruc- 
tion target's address. We add a nop instruction as the first 
instruction of every Jimple methods. This way, if the first 
Dalvik instruction is a jump or if the jump's target corre- 
spond to a non-yet generated Jimple statement, we redirect 
it to the this nop Jimple instruction. We correct those Jim- 
ple jump instructions once the whole Dalvik bytecode of the 
method has been processed: at this point we know the tar- 
get Jimple statement mapped to the Dalvik jump's target ad- 
dress. The Jimple nop instruction we add is removed during 
the Jimple optimization step. 

Branching instructions often rely on the result of a 
comparison of two registers. Dalvik comparisons between 
double or float are explicit and provide typing informa- 
tion. However, when a register r is compared with zero 
one has to check the type of r. If it is an object, we 
change the zero value to null since it is a comparison be- 
tween objects. We do this change when the fast typing 



component has finished. Indeed, comparisons do not in- 
fluence the type inference. For example, the Jimple state- 
ment generated from 02 in Figure 4 has to be updated to 
use NullConstant instead of IntConstant (0) . If this 
is not handled correctly the bytecode generated from Jim- 
ple statements does not run correctly and generates an 
exception similar to the following one: Exception in 
thread "main" java.lang.VerifyError: Expecting 
to find integer on stack. 

Dexpler enables us to transform Dalvik bytecode to Jim- 
ple representation. From there, Soot can be used as a static 
analysis tool to analyze the code. The next Section evaluates 
Dexpler. 

5. Evaluation 

We evaluate Dexpler using test cases, and one Android ap- 
plication: Snake. 

5.1 Test Cases 

The first step is to generate the Dalvik bytecode for every test 
case. The test cases are written in Java then compiled into 
Java bytecode using javac and finally converted into Dalvik 
bytecode using dx. The second step is to execute Dexpler on 
every generated Dalvik bytecode test case. This generates 
. j imple and . class files. We then compare the execution 
result from of the versions produced from the original Java 
bytecode and the Java bytecode produced by Soot from the 
Dalvik bytecode. Executions of the . class files give the 
correct result. 

We wrote test cases for arithmetic operations, branches, 
method calls, array initialization, string manipulation, null 
and zero usage, exceptions and casts. 

Since simple test cases do not reflect a real application we 
also evaluated our tool on one Android application. 

5.2 Android Application 

The snake application is a demonstration application devel- 
oped by the Android team to showcase the Android plat- 
form. 5 It features 1 1 classes, 39 methods and was written in 
550 lines of Java code. The generated Dalvik bytecode takes 
14 KiB and contains 884 Dalvik instructions. 

From the Dalvik bytecode of the Snake application we 
generate Jimple code in one second (duration for the Dalvik 
to Jimple conversion only). Then we ask Soot to generate 
Java bytecode from the Jimple representation. We convert 
the Java bytecode back to Dalvik, repackage an Android 
application and launch it on the Android emulator. 

The application runs smoothly and the game is working. 

5.3 Static Analysis on Snake 

We use Soot to generate a call graph of the Snake application 
as well as a control flow graph represented in Figure 5 in 14 

5 http : //developer . android . com/resources/samples/Snake/ 
index.html 
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Figure 5. Control Flow Graph for addRandomApple 
Method Extracted from the Generated Jimple Representa- 
tion. 

seconds (duration from the launch time of Soot until Soot 
has finished). We perform this to check that the generated 
call graph and CFG correspond to the original code meaning 
that the conversion from Dalvik to Jimple is correct for this 
code. 

We have successfully tested our prototype tool on test 
cases as well as on an Android application. 

6. Current Liminations 

The current version of Dexpler is able to transform Android 
applications such as the Snake game. 

However, it does not handle optimized Dalvik (odex) 
opcodes. 

Moreover, when inferring types for ambiguous declara- 
tions the algorithm supposes that the Dalvik bytecode is le- 
gal in the sense that it was generated from Java source code 
and not hand-crafted by malicious developers. In the later 
case assumptions such as "comparisons always involve vari- 
ables with the same type" may not hold anymore and may 
make Dexpler to infer wrong types. 

7. Related Work 

To our knowledge no existing tool directly converts Dalvik 
bytecode to Jimple. We either found tools to convert Dalvik 
bytecode to Java bytecode or tools to disassemble and/or as- 



semble Dalvik bytecode using an intermediate representa- 
tion. 

Dalvik to Java Bytecode Converter Ded [7] is a Dalvik 
bytecode to Java bytecode converter. Once the Java bytecode 
is generated, Soot is used to optimize the code. Dex2jar 
[16] also generates Java bytecode from Dalvik bytecode 
but no not use any external tool to optimize the resulting 
Java bytecode. Undx [17] is also a Dalvik to Java bytecode 
converter but seems to be unavailable. 

We on the other hand do not directly generate Java byte- 
code but Jimple code. From there, since the Jimple code is 
within Soot, we can generate Java bytecode as well. 

Dalvik Assembler/Disassembler Smali [2] or Androguard 
[5] can be used to reverse engineer Dalvik bytecode. They 
use their own representation of the Dalvik bytecode: they 
can not leverage existing analysis tools. 

Our tool, use Soot's internal representation which allows 
existing tools to analyze/transform the Dalvik bytecode. 

8. Conclusion 

We have presented Dexpler 6 a Soot modification with en- 
ables Soot to analyse Dalvik bytecode and thus Android ap- 
plications. This tool leverages dedexer for the parsing of 
Dalvik dex files and Soot's fast typing component for the 
type inference. 

Dexpler converts every Dalvik instruction to Jimple. We 
are working on improving Dexpler to make it robust to yet 
unhandled typing issues. Once this step is done we will look 
at the performance of this tool compared to current Java 
bytecode generation and analysis tools. 
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A. Jimple Code 



Table 1 : Jimple Code representation of Dalvik Instructions 



Opcode 


Oncode name 


limnle Code 


UxUU 


nop 


nop 


UxUl 


move vx,vy 


vx = vy 


uxuz 


move/from 16 vx,vy 


vx = vy 


A V A1 

VJXVJj 


move/ 16 


vx = vy 


UXU4 


move-wide 


vx = vy 


UXUJ 


move-wide/froml6 vx,vy 


vx = vy 


uxuo 


move- wide/1 6 


vx = vy 


uxu/ 


move-object vx,vy 


vx = vy 


UxUo 


move-object/froml6 vx,vy 


vx = vy 


uxuy 


move-object/16 


vx = vy 


A V A A 

UxUA 


move-result vx 


vx = mres 


UxUr> 


move-result-wide vx 


vx = mres 


A V A^ 


move-result-object vx 


vx = mres 


A v Ar\ 
UXUJJ 


move-exception vx 


vx = mres 


UXUli 


return-void 


return 


A V AD 

UXUr 


return vx 


return vx 


A v 1 f\ 

uxiu 


return-wide vx 


return vx 


UXl 1 


return-object vx 


return vx 


Uxlz 


const/4 vx,lit4 


vx = lit4 


Uxl3 


const/ 16 vx,litl6 


vx = lit 16 


UX14 


const vx, lit32 


vx = lit32 


A v 1 C 

UXl J 


const/ nign to vu, lit to 


vx = litlo << Id 


UXlO 


const- wide/1 6 vx, lit 16 


vx = lit 16 


A v i n 
UXl / 


const-wide/32 vx, lit32 


vx = lit32 


A v 1 Q 

UXlo 


const-wide vx, lit64 


VX = llto4 


uxiy 


const-wide/highl6 vx,litl6 


VX = lltlO << 48 


fW 1 A 

UXlA 


const-string vx,string jd 


vx = string 


Ox IB 


const-string-jumbo vx,string 


vx = string 


OxlC 


const-class vx,type jd 


vx = class "type" 


OxlD 


monitor-enter vx 


monitorenter vx 


OxlE 


monitor-exit vx 


monitorexit vx 


OxlF 


check-cast vx, type Jd 


checkcast = (type) vx 


0x20 


instance-of vx,vy,type_id 


vx = vy instanceof type 


0x21 


array-length vx,vy 


vx = length(vy) 


0x22 


new-instance vx,type 


vx = new type 


0x23 


new-array vx,vy,type jd 


vx = new type[vy] 


0x24 


filled-new-array 

{ p arameters ) , type id 


vx = new array _type[size]; vx[0] = el; ... vx[N] = eN; 


0x25 


filled-new-array-range 
{vx..vy},type jd 


vx = new array Jype[size]; vx[0] = el; ... vx[N] = eN; 


0x26 


fill-array-data 
vx,array_data_offset 


vx[0]=el;... vx[N] = eN; 


0x27 


throw vx 


throw vx 


0x28 


goto target 


goto target 


0x29 


goto/ 16 target 


goto target 


0x2A 


goto/32 target 


goto target 


0x2B 


packed-switch vx,table 


switch (vx) { case CI: goto target 1; ... case CN: goto targe tN; } 



Table 1 : Jimple Code representation of Dalvik Instructions 



Opcode 


Opcode name 


Jimple Code 


0x2C 


*;nar*;p-*;wi tph vy tahlp 


siwitph ^vy^ < pasip * tyntn tartyptl * pasip f^TV* tyntn tartyptlV* \ 

3 W1LL11 ^ V A j | ^LijL- 1 . liVJLVJ LOl t^Ll , ... LtlSt V^l>. liVJLVJ Ltllgt^Ll>, f 


0x2D 


pmnl-flnat 

^lllJJl 11VJLIL 


vy — vv pmnl V7 

v a — v y \^±iiiji v / - 


0x2E 


rmno-flnat vy vv \n 

L^lllJJg HVJtlL VA, V^, VZ, 


vy — vv pmnty V7 

VA — V^ L^lllJJg VZ, 


0x2F 


pmnl-Hnnhlp vy vv v7 

L^lllJJl LIVJLIU1C VA, V^,VZ, 


vy — vv pmnl V7 

VA — V^ L^lllJJl VZ 


0x30 


pmnty-Hnnhlp vy vv \n 

1/111IJ UVJ LIU1C V A, V V , Vi 


vy — vv pmnty V7 

VA — V y L^lllUl; VZ, 


0x31 


rmn-lniiQ vy vv \n 

L^lllJJ IVJllg VA, V^, VZ. 


vy — vv pmn V7 

VA — V^ L^lllJJ vz, 


0x32 


if_pn vy vv tarcpt 

11 CLj VA, VJ/,LalgCL 


if* A/y vv^ tyntn tartypt" 

11 V V A V^ } g,VJ LVJ LtilgCL, 


0x33 


iT-Tip vy vv tartrpf 

11 11C V A, V V , Ltll cCL 


if* A/y I — vv^ tyntn tartypt" 

11 l, V A . — V y J liVJLVJ Lcllt;CL, 


0x34 


if-lt vy vv taropt 

11 1L VA,V V , LulgCL 


if* (\/\ <C tyntn tartypt* 

ii v v a \ v y } gvjLVJ Laigk/L, 


0x35 


if-typ vy vv tartypt 
ii v a, v y , Laitc l 


if* (vy "> — vv^ tyntn tartypt* 

11 ^ V A ^ — V V J liVJLVJ LalgCL, 


0x36 


if-tyt vy vv tartrpf 

11 iiL V A,V y^LOlcLL 


if (\/y ^> vv^ tyntn tartypt* 

11 IV A ^- V V J ii VJ LVJ L til si \^ L , 


0x37 


if-1p vy w tarty pt 

11 1C V A, V y,LalgCL 


if A/y <^ — vv^ tyntn tartypt* 

11 V V A ^\ — *jj ^,VJ LVJ LtllgCL, 


0x38 

UAJ O 


if-pn7 vy tartypt 

11 Clji VA,LtllgCL 


if ('vy (Y\ antn tartypt* 

11 V V A \J ) g,VJLVJ Ltll^CL, 


0x39 


if-iiP7 vy tartypt 

11 11CZ, V A, Ltll iiC L 


if A/y ! — 0^ tyntn tartypt* 

11 l V A . — \J ) VJ LVJ LolcCL, 


0x3A 


if-1t7 vy tartypt 

11 1LZ, V A, Ltll 1; t- L 


if ^vy <^ (X\ tyntn tartypt* 

11 V V A \J J t;VJ LVJ LtllliCL, 


0x3B 


if-typ7 vy tartypt 

11 tCA VA,Ltlll;CL 


if ^ vy "~> — OA tyntn tartypt* 

11 l V A ^ — \J ) gVJ LVJ Ltll^CL, 


0x3C 


if-tyt7 vy tartypt 

11 1; LZ, V A, LalcC L 


if fvY ^> 0^ tyntn tartypt* 

11 1 V A ^ U } ^VJLVJ LulgCL, 


0x3D 


if-1p7 vy tartypt 

11 ItA V A, Ull 


if (vy <C — 0^ tyntn tartypt* 

11 V ' A \ — \J } gVJLVJ LalgCL, 


0x3E 


iinn*;pH '"IF 

Lll 1 LI J tU _ 1—i 




0x3F 


limi^pH '"IF 

Lll 1 Li J tU _ 1 




0x40 


nmiQpH zLO 

Lll 1 U S CLl \J 




0x41 


nmiQpH zl1 

LlllLl&CLl_"T 1 




0x42 


TimiQpH AD 

LlllLl&CLl_*TZ, 




0x43 


nmiQpH A!\ 

Lll 1 Ll O CLl J 




0x44 


a typt vy vv V7 

tlgCL VA, V J,VZ. 


VY — VvTv7l 

v a — v y [ v z,j 


0x45 


a typt -xxn Hp vy vv V7 

tlgCL W1LIC VA,Vj,Vi 


VY — VvTv7l 

v a — v y [ v z,j 


0x46 


atypt-nhippt vy vv V7 

Ll L-.V. 1 VJUJ\^\^L V A, V J, VZ. 


VY — wTv7l 

V A — V VI V Z,J 


0x47 


a typt-hnnlpan vy vv V7 

Ll I U\JVJl\^Lill V A, V V,VZj 


VY — wTv7l 
VA — * jL J 


0x48 


atypt-hvtp vy vv V7 

Ll ^V. L V L\_- V A, v y, v / - 


VY — wTv7l 
VA — * jL J 


0x49 


atypt-phar vy vv V7 

ClcCl 1-11CU *A, V y, Vi 


VY — VvTv7l 

v a — v y l v z,j 


0x4A 


atypt-Qriort vy vv V7 

LigCL S11VJ1L VA,VJf,VZ 


VY — VvTv7l 

v a — v y l v z,j 


0x4B 


annt vy vv V7 

LiJJLlL VA, V y,VZ. 


VvTv7l — VY 

v y l vz,j — v a 


0x4C 


annt-wiHp vy vv V7 

LiJJLlL W1LIC VA,Vjf,VZ 


VvTv7l — VY 

v y l vz,j — v a 


0x4D 


annt-nhippt vy vv V7 

dUUl UUJ C-L/ L VA,V y, VZ 


VvTv7l — VY 
VV[_VZ,J — VA 


0x4E 


annt-hnnlpan vy vv V7 

LiJJLlL UVJVJlCtlll VA,V y, VZ, 


VVlV7l — VY 

v y l vz,j — v a 


0x4F 


annt-hvtp vy vv V7 

tlJJ LIL Uy LC- VA,V y,vz 


wfv7l — VY 
V V [ VZ,J — VA 


0x50 


annt-phar vy vv V7 

Ll 1) Ll L V 1 iLll »A, V V, VZ; 


wTv7l — VY 
v y l v Z, J — V A 


0x51 


aniit-*;hnrt vy vv V7 

tlJJ LIL JllVJl L VA,V y,vz 


wfv7l — VY 
V V [ VZJ — VA 


0x5? 


i typt vy vv fiplH iH 

l^CL VA, V^, 11C1LI_1LI 


vy — fiplH iH 

VA — 11C1LI_1LI 


0x53 


itypt-wiHp vy vv fiplH iH 

IcCL W 1UL V A, V V , 11C1LI_ILI 


vy — fiplH iH 

VA — 11C1LI_1LI 


0x54 


itypt-nhippt vy vv fiplH iH 

IgCL VJUJCL^L V A, V V,11C1LI_1LI 


vy — fiplH iH 

VA — 11C1LI_1LI 


0x55 


i typt-hnnlpan vy vvfiplH iH 

IctL UVJVJlt^ till V A, V y ,11C^1U_1U 


vy — fiplH iH 

VA — llt^lU_lU 


0x56 


iget-byte vx,vy,field Jd 


vx = field jd 


0x57 


iget-char vx,vy,field Jd 


vx = field jd 


0x58 


iget-short vx,vy,field_id 


vx = field jd 


0x59 


iput vx,vy, field jd 


field jd = vx 


0x5A 


iput-wide vx,vy, field jd 


field jd = vx 


0x5B 


iput-object vx,vy,field id 


field jd = vx 


0x5C 


iput-boolean vx,vy, field jd 


field jd = vx 



Table 1 : Jimple Code representation of Dalvik Instructions 



Opcode 


Opcode name 


Jimple Code 


0x5D 


innt-hvtp vy vv fiplH iH 

1 |_> LI I U V LL V A, V VjllwlU_lU 


fiplH iH — vy 

11L lu IU — V /\ 


0x5E 


iniit-phar vy vv fiplH iH 

1JJLIL Lvlltll VA, V V,lltlU_lU 


fiplH iH — vy 

11L1L.1 IU — VA 


0x5F 


i nnt-Qhnrt vy vv fiplH iH 

1JJLIL &11U1 L V A , V , 1 1 C 1 LI _1 LI 


fiplH iH — vy 

11C1LI_1LI — VA 


0x60 


QtTPt VY fiplH iH 
SgCL V A , 1 1 CI LI 1 LI 


VY — fiplH iH 

VA — 11C1LI_1LI 


0x61 


copt-wiHp vy fiplH iH 

SgC L W 1UL V A, 11C1LI_1U 


VY — fiplH iH 

VA — 11C1LI_1LI 


0x62 


Q (TPt-ohlPPt vy fiplH iH 
SgCL UUJCCL VA,11C1LI_1LI 


VY — fiplH iH 

VA — 11C1LI_1LI 


0x63 


« opt-hnnlpan vy fiplH iH 

&gCL UUUlCdll V A, 1 1 CI LI 


VY — fiplH iH 

VA — 11C1LI—1LI 


0x64 


QtTPt-hvtP vy fiplH iH 
SgC L Uy LC V A, 11C1U_1.U 


VY — fiplH iH 

VA — 11C1LI—1LI 


0x65 


sitTPt-phfir vy fiplH iH 

Jet L L, 1 Itll V A, 11C1U_1U 


vy — fiplH iH 

VA — 11C1U_1U 


0x66 


trpt-^hnrt vy fiplH iH 

JgtL JllVJl L VA^lltlU IKJ. 


vy — fiplH iH 

VA — 11C1U_1U 


0x67 


sput vx, field jd 


field Jd = vx 


WAVJO 


spui-wiuc VX, 11C1U_1U 


11C1U_1U — VX 


0x69 


sput-object vx,fiekLid 


field Jd = vx 




sput-boolean vx, field jd 


field_id = vx 


0x6B 


sput-byte vx,field Jd 


field Jd = vx 


UXOL- 


sput-char vx,field_id 


field Jd = vx 


0x6D 


sput-short vx,field id 


field Jd = vx 


0x6b 


invoke-virtual { parameters }, 
methodtocall 


invoke-virtual 


0x6F 


invoke-super 

{parameter}, methodtocall 


invoke-special 


0x70 


invoke-direct { parameters }, 
methodtocall 


invoke-special 


A v 71 
UX/ 1 


invoke-static {parameters}, 
methodtocall 


— 

invoke-static 


UX/Z 


invoke-interface 
{parameters } ,methodtocall 


invoke-interface 


UX/ j 


unused_73 




UX/4 


invoke-virtual/range 
{vx..vy}, methodtocall 


— ■ 

invoke-virtual 


Ua / J 


invoke-super/range 


— j — 

invoke-special 


UX / O 


lllVUKc-UircCL/rallgc 

J \ 7 V \7\7 L IHPtn/\/ It ^A/*') 1 1 

1 VA..Vy r,lllCLllULlLUCdll 


lllVUKC-SpCcldl 


0y77 
UX / / 


lilVUKC-aLdLlC/ldilgC 

4 vy vv V mpthoHtopnll 

I VA..VJ f ,lllCLllULlLUCdll 


lllVUls.C-aLd.LlC 


0x78 


1 nvolrp-1 ntptfapp-frin ctp 

ill V U1\_C 111 LCI 1 uLt 1 til 1 l_,v, 


i nvnlfP-i n1"PTTnf*p 

111VU1S.C lllLClldCC 


0x79 


nmiQpH 7Q 

L111LISCLI_ / y 




0x7A 


nmiQpH 7 A 

LlllLlSCLl— / 1\. 




0x7B 


nptr-int vy vv 

iiv. l, nil v a., v y 


vx = - vy 


0x7C 


nnt-int vy vv 

11VJ L 111L V A, V V 


VY — VV A ( - 1 ^ 

va — vy ^ l j 


0x7D 


riper-lone* vy vv 

llCg lUllg VA,Vy 


vx = - vy 


0x7E 


nnt-lnntr vy vv 

11VJ L IVJllli V A, v y 


VY — VV A ( - 1 ^ 

va — vy ^ i j 


0x7F 


neg-float vx,vy 


vx = -vy 


0x80 


neg-double vx,vy 


vx = -vy 


0x81 


int-to-long vx, vy 


vx = (long) vy 


0x82 


int-to-float vx, vy 


vx = (float) vy 


0x83 


int-to-double vx, vy 


vx = (double) vy 


0x84 


long-to-int vx,vy 


vx = (int) vy 


0x85 


long-to-float vx, vy 


vx = (float) vy 



Table 1 : Jimple Code representation of Dalvik Instructions 



Opcode 


Opcode name 


Jimple Code 


0x86 


Inntr-tn-Hnnhlp vy vv 

IVJllti LVJ V.1VJ Li Ul\_- V yV, V V 


vy — fHoiihlp^ vv 

VA — v V-ivJLiuiV-' 7 v y 


0x87 


flnat-tn-int vy w 

IIVJUL LVJ 1111 V yv, vy 


vy — fint^ vv 

VA — V 111L } v y 


0x88 


flon t-to-1on o vy vv 

11VJO.L LVJ IVJllg VA,VJ 


vy — nnti0^ vv 

VA — yixjYYQ) V y 


0x89 

UA0 7 


flont-to-Hoi lhlp VY vv 

11VJO.L LVJ LIVJLLU1C VA, \y 


vy — ^Hoiihlp^ vv 

VA — lUVJLLUlCy" \y 


0x8A 


Honhl^-to-i nt vy vv 

UVJ LLU1C LVJ 111 L V A, V y 


vy — ^int^ vv 

VA — V^lll L ^ V y 


0x8B 


Honh1p , -to-1orKT vy vv 

V-IVJUUIC LVJ IVJllg VA, \y 


vy — Mrvntx^ vv 

VA — \l\JlLgJ Vy 


0x8C 


Honhlp-to-float vy vv 

LIVJLLU1C LVJ 11VJHL VA, \y 


vy — ('flont^ vv 

VA — \LlVJa.lf Vy 


0x8D 


i nt-tn-hvtf 1 vy vv 

111L LVJ Uy LC V A, v y 


vy — fnvtf 1 ^ vv 
va — v^ijyLC^ v y 


0x8E 


i nt-to-phfir vy vv 

111L LVJ L-lltll V A, v y 


vy — ^phfir^ vv 

VA — ^i/iicu ) v y 


0x8F 


i nt-tn-silinrt vy vv 

111L LVJ JllVJl L V A, V V 


vy — fchnrt^ vv 
va — ^anvji *-J v y 


0x90 


aHH-int vy vv V7 

llUU 111L V A, V y, V / - 


VY — VV -1- V7 
v a — v y i v a 


0x91 


Qllh-int VY VV V7 
SLLU 111L VA,Vj,VZ. 


VY — VV - V7 

v a — v y vz. 


0x9? 


iniil-int vy vv V7 
in ui nil va, vy, vZ; 


VY — VV ^ V7 

v a — v y vz. 


0x93 


niv-int vy vv \n 

Lll V 1111 VA,VV,VA 


VY — VV / V7 

va — vy / vz. 


0x94 


T"PTVl-int VY VV V7 
1 Clll 111L va,vv,va 


VY — VV @/n V7 
VA — VV /V V A 


0x95 


anH-int vy vv \n 

allU 111L VA, V^, VZ. 


VY — VV Rl V7 
VA — Vy OC VZ. 


0x96 


nr-int vy vv V7 

VJl 111L VA, vy, vz 


VY — VV 1 V7 
V A — V J' | VZ. 


0x97 


Ynr-int vy vv V7 

AVJl 111L V A, V V, V A 


VY — VV A V7 
V A — v y vz. 


0x98 


sihl-int vy vv V7 

Dili nil v a, v y, vz. 


VY — VV <"" <""" V7 
V A — V y \ \ V A 


0x99 


sihr-int vy vv V7 

Jill 111L VA, vy, VA 


VY — VV V7 
V A — V y ^ ^ V A 


0x9A 


n^hr-int vy vv V7 
Uoiii nil va, vy, vz. 


VY — VV V7 
V A — v y ^ ^ V A 


OxQR 

V J A 7 1 ) 


nHH-1r\ntr vy vv \n 

dUU IVJllg VA, Vy, VZ. 


VY — VV -1- V7 
VA — V^ i VA 


0x9C 


Qllh-lontT VY VV V7 
SLLU IVJllg VA,Vy,VA 


VY — VV - V7 
V A — V J' V A 


0x9D 


miil-lnntr vy vv \n 
iiiui ivjiig v a, v y, v a 


VY — VV ^ V7 
V A — V y V A 


0x9E 


HlV-lontT VY VV V7 
LllV IVJllg VA, Vv, VA 


VY — VV / V7 
VA — V^ / VA 


0x9F 


rpm-lnn tr vy vv V7 

1C111 IVJllg VA,VV,VA 


VY — VV ®/n V7 
VA — VJ 1 /CVA 


OxAO 


anH-lnntr vy vv V7 

uiiu ivjiii; v a, v y, vz. 


VY — VV A' - V7 
V A — V y OC V A 


OxAl 


or-lnntr vy vv V7 
vji ivjiii; v a, v y, v a 


VY — VV 1 V7 
V A — V V V A 


0xA2 


Yrvr-lnntr vy vv V7 
avji ivjui; v a, v y, v a 


VY — VV A V7 
V A — V V V A 


0xA3 


Qhl-lontr VY VV V7 
Olll IVJllg VA, V^, VZ. 


VY — VV <""' <^ V7 
VA — VV \ \ VA 


0xA4 


Qhf-lontT VY VV V7 
Sill IVJllg VA,V V,VA 


VY — VV V7 
VA — VV ^ ^ VA 


0xA5 


llQhf-lontT VY VV V7 
LLS111 IVJllg VA, V^, VZ. 


VY — VV ^> V7 
VA — VJ 1 ^ / VA 


0xA6 


aHH-flont vy vv V7 

tlUU 11VJO.L VA,Vy,VA 


VY — VV -X- V7 
VA — V^ i VA 


0xA7 


Qllh-flont VY VV V7 
ALUJllVJtlL VA,VV,VA 


VY — VV - V7 
VA — vy VA 


0xA8 


mill-flont VY VV V7 
111LL1 11VJO.L VA, V^, VZ. 


VY — VV ^ V7 
V A — V V A 


0xA9 


Hiv-float vy vv V7 

Ul V 11VJU.L VA, vy, VZ. 


VY — VV / V7 
VA — vy / VA 


OxAA 


rPTTi-flnat vy vv V7 

IV^lll HVJllL V A, v y, V a 


VY — VV % V7 
V A — V y /t/ V A 


OxAB 


aHH-Honhlp vy vv V7 

tlV-lLl UVJ LiUlt^ VA,VV,VA 


VY — VV -1- V7 
VA — V V l VA 


OxAC 


Qllh-Hoilhlp VY VV V7 
SLLU UVJUUIC VA,VJ,VZ 


VY — VV - V7 
V A — V V A 


OxAD 


mnl -Honhlp vy vv V7 

111LL1 LIVJLLU1C VA, VV, VZ. 


VY — VV ^ V7 
V A — V y V A 


OxAE 


niv-nminlf 1 vy vv \n 

LllV LIVJLLU1C VA, Vy, VZ. 


VY — VV / V7 
VA — Vy / VA 


OxAF 


rPTTl-Hoilhlp VY VVV7 

i tin uuiiuit va,vv,vz. 


VY — VV % V7 
VA — V V /V VA 


OxBO 


add-int/2addr vx,vy 


vx = vx + vy 


OxBl 


sub-int/2addr vx,vy 


vx = vx - vy 


0xB2 


mul-int/2addr vx,vy 


vx = vx * vy 


0xB3 


div-int/2addr vx,vy 


vx = vx / vy 


0xB4 


rem-int/2addr vx,vy 


vx = vx % vy 


0xB5 


and-int/2addr vx, vy 


vx = vx & vy 


0xB6 


or-int/2addr vx, vy 


vx = vx vy 



Table 1 : Jimple Code representation of Dalvik Instructions 



Opcode 


Opcode name 


Jimple Code 


0xB7 


Ynr-int/^aHHr vy vv 

AVJ1 111L/Z.UUU1 V yV, V V 


VY — VY A VV 
V A — V A v y 


0xB8 


^hl-int/^aHHr vy vv 

dill 1111/ _LlL.lL.ll V A , V y 


VY — VY <"" <""" VV 
V A — V A \ \ V y 


0xB9 

UAU7 


Qhr-i nt/^nHHr vy vv 

Sill 1111/ —tlLlLll va, 


VY — VY """> VV 
VA — VA ^ v y 


OxBA 


11 Qhv-int/^nHHr vy vv 

USUI 1111/ _tlLl Lll va, 


VY — VY VV 
VA — VA ^ vy 


OxBB 


nHH-Inn o 10 s\f\f\v vy vv 

tlLlLl 1VJ111;/ z_l1L1L1 1 V A, V V 


VY — VY -I- VV 
VA — VA i vy 


OxBC 


Qiih-lnn tr/^nHHr vy vv 

S LIU lVJllg/Z.£lLlLll VA, V Y 


VY — VY - VV 
V A — V A v y 


OxBD 


miil-lnna/^aHHr vy vv 

111L11 l V.) 1 It;/ z_ tlLlLl 1 VA, V Y 


VY — VY ^ VV 
V A — V A v y 


OxBE 


Hi v-lnntr/^nHHr vy vv 

LI I V IVJllt/ z_l1L1L1I V A, V V 


VY — VY / VV 
VA — VA / vy 


OxBF 


rpm-lnntr/^aHHr vy vv 
i tin ivjiii;/ Ziduui v a, v y 


VY — VY ®/r> VV 
VA — VA /V v y 


OxCO 


nnH-lnntr/^aHHr vy vv 

ill 1LI IVJllli/ ZiflUUl V A, v y 


VY — VY R? VV 
VA — VA CX. V V 


OxCl 


nr-lnntr/^aHHr vy vv 

V -M IVJllli/ _- UUU1 V TV, V y 


VY — VY 1 VV 
V A — V A V y 


0xC2 


Ynr-1nii(r/?!irlHr vy vv 

AVJ1 IV.) 1 l£;/ x— LlLlLl 1 VA, V^ 


VY — VY VV 
V A — V A v y 


OxC3 


Qhl -Ion tr/^aHHr vy vv 

Olll IVJllg/ _lIL1LU VA, V^ 


VY — VY <""' <"""" VV 

va — va \ \ vy 


0xC4 


Qhi*-1nn tr/^nHHr vy vv 

Sill ill./ z_ LlLlLl 1 V A, v y 


VY — VY VV 
V A — V A / V y 


0xC5 


n Qnr-lon tr/^nHHr vy vv 

LIS111 IV.) 1 l£;/ x— LlLlLl 1 va, \y 


VY — VY ^> VV 
VA — VA ^ ^ \y 


0xC6 


5\r\r\-f\r\5it fJi^rlrlv vy vv 

aUU 11VJO.L/ Z/tlLlLll VA,VV 


VY — VY -I- VV 
VA — VAT V^ 


0xC7 


Qiih-flnnt/^nHHr vy vv 

&LIU 11VJHL/Z.O.LIL11 VA,VV 


VY — VY - VV 
V A — V A v y 


0xC8 


mnl-flofit/'^aHHr vy vv 

111L11 11VJLIL/ _LlL.lL.ll V A, V V 


VY — VY * VV 
V A — V A V y 


0xC9 


Hi v-flnat/^nHHr vy vv 

Ul V llVJtlu —LlLlLU V A, v y 


VY — VY / VV 
VA — VA / vy 


OxCA 


rpm-flnat/^aHHr vy vv 

1 till llWCiL/ _ tlLl Ll 1 V A, V V 


VY — VY % VV 
VA — VA /V v y 


OxCB 


nHH-HrMihlp/^nHHi* vy vv 

tlLlLl LlVJUUlw x_tlLlLll V A, V y 


VY — VY -I- VV 
VA — VA i vy 


Oxrr 

UAVA- 


Qiih-Hnnhlp/^nHHr vy vv 

SLIU LIVJLIU1C/Z.L1LIL11 VA, V^ 


VY — VY - VV 
V A — V A v y 


OxCD 


mill -Hoiihlp/^nHHi* vy vv 

111L11 LlVJLlUlC/Z/LiLlLll VA, V^ 


VY — VY ^ VV 
V A — V A v y 


OxCE 


Hi v-Honhlp/^nHHr vy vv 

Lll V LIVJ LIUlw z_ clLlLU V A, V y 


VY — VY / VV 
VA — VA / vy 


OxCF 


rpm-Hrwihlp/^nHHr vy vv 

1C111 LlVJLlUlC/Z/tiLlLll VA,V y 


VY — VY ®/n VV 
VA — VA /V VV 


OxDO 


nHH-int/1it1 f\ vy vv 1it1 f\ 

tlLlLl 111L/11L1U VA,V^,11L1U 


VY — VV -I- 1lt1 f\ 
VA — V^ T11L1VJ 


OxDl 


*;iih-int/1it 1 f\ vy vv 1it1 f\ 

J\XvJ 111L/ 11L _L v_J V A, V V ,11 L _L \J 


VY — vv - litlfi 

VA — V y 11L_LV_/ 


0xD2 


mill -int/lit 1 f\ vy vv 1it1 f\ 

111 Lll 111L/ 11L _L \J VA, V V,11L1U 


VY — VV ^ lltlfi 
VA — V V 11L.HJ 


0xD3 


Hiv-int/1it1 f\ vy vv 1it1 f\ 

U.1 V 1111/11L1_\J V A, V V,11L1U 


VY — VV / 1it1 f\ 
va — vy / 1 1 1 1 u 


0xD4 


rpm-int/li t 1 f\ vy vv 1i 1 1 f\ 

1 till 111 L/ 11L1VJ VA, VV,11L1\J 


VY — VV °/n 1lt1 ft 
VA — V y iV 11L1VJ 


0xD5 


nnH-int/1it1 f\ vy vv lit 1 6 

tlllLl 111L/11L1VJ VA,V^,11L1U 


VY — VV Rl 1lt1 f\ 
VA — V^ OC 11L1VJ 


0xD6 


nr-int/1it1 f\ vy vv 1i 1 1 f\ 

VJl 111L/11L1\J VA,V^,11L_1U 


VY — VV I 1lt1 f\ 
va — v y | 11L1VJ 


0xD7 


YOT"-1Tlt/llt 1 f\ vy w1it16 
AVJ1 111L/11L1_\J VA, VV,11L1VJ 


VY — V V ^ 1 1 1 1 f\ 
VA — V^ 11L1VJ 


0xD8 


nHH-int/litS vy vvlitS 

LiLlLl 111L/ 11 LO VA, V V ,llLO 


VY — VV -I- litS 
VA — V y i 11 LO 


0xD9 


Qiih-int/1it& vy vv 1it& 

SLIU 111L/11LO VA,V^,llLO 


VY — VV - 1lt& 

v a — v y 11LO 


OxDA 


mnl-int/lit-8 vy vvlitS 

111 Lll 1111/ 1 1 L O V A, V V ,11 LO 


vy — vv * 1it& 

VA — V V 11LO 


OxDB 


Hiv-int/1it& vy vvlitS 

Ul V 1111/ lilt) VA, V V,llLO 


vy — vv / 1i t8 

V A — V V / 11 LO 


OxDC 


rpm-int/lit8 vy vvlitS 

1 till 1111/ 11 LO V A, V V ,11 LO 


vy — vv % 1it8 

VA — V y /V 11 LO 


OxDD 


nnH-int/1it& vy wlitS 

tlllLl 111L/11LO VA,V^,llLO 


VY — VV Rt 1lt& 
VA — V^ OC 11 LO 


OxDE 


nr-int/1it& VY VV 1lt& 
VJl 111L/11LO VA, VV, 11 LO 


VY — VV 1 1lt& 
VA — V V 11 LO 


OxDF 


YOT"-int/1lt& VY VV 1lt& 
AVJ1 111L/11LO VA, V^, 11LO 


VY — VV A 1lt& 
V A — v y 11LO 


OxEO 


sh1-int/lit8 vy vv h\R 

Jill 111L/ 11 LO V A, V V , 11 LO 


vy — vv -I- litS 

VA — V V ! 11 LO 


OxEl 


shr-int/lit8 vx, vy, lit8 


vx = vy + lit8 


0xE2 


ushr-int/lit8 vx, vy, lit8 


vx = vy + lit8 


0xE3 


unused_E3 




0xE4 


unused_E4 




0xE5 


unused _E5 




0xE6 


unused_E6 




0xE7 


unused_E7 





Table 1 : Jimple Code representation of Dalvik Instructions 



Opcode 


Opcode name 


Jimple Code 


OyFS 


U 1 1 LI i C LI _ J_> O 




OyFQ 


nniicpn Ft) 




AvFA 
UADn 


nniicpn FA 

Lll 1 Ll a CU _C/\ 






nniicpn FR 
Ll 1 1 Ll a C Ll _ J_j D 




OyFC 


linnet*/"! Fl^ 
Ll 1 1 Ll S C Ll _ J_j 




OyFD 


Ll 1 1 Ll S C Ll _ \2jYJ 




OyFF 


CACL-LlLC-lllllllC 

< nara mptprs; V inlinp TD 

| |_> Lll Ll 1 1 IV. 1 ,1 [ .llillliV. 1 l_V 


— j 

odex 


OxEF 


iinn*;pH FF 

Ll 1 1 Ll J L^ Ll _ J_/ 1 




OxFO 


i nvnlrp-Hirppt-pmntv 

111 V VJIVt^ L.1 11 V. L-l l;iiijjl y 


odex 


OxFl 


unused_Fl 




OyF? 


l^Cl-qUlCJA VA,Vy,011SCl 


odex 


0xF3 


iget-wide-quick vx,vy,offset 


odex 


fh-FzL 


iget-object-quick vx,vy,offset 


odex 


0xF5 


iput-quick vx,vy,offset 


odex 


A,, r?/: 

UXrO 


iput-wide-quick vx,vy,offset 


odex 


0xF7 


iput-object-quick vx,vy,offset 


odex 


Uxho 


invoke-virtual-quick 
{parameters },vtable offset 


odex 


Uxr^ 


invoke-virtual-quick/range 
{parameter range}, vtable offset 


— 

odex 


OyFA 
WArrt 


lnvoKe-super-quiciv 
{parameters },vtable offset 


— 

odex 


OxFB 


invoke-super-quick/range 
{register range}, vtable offset 


odex 


OxFC 


unused_FC 




OxFD 


unused_FD 




OxFE 


unused JFE 




OxFF 


unused JFF 





